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BID MESSAGE PROCESSING FOR REALTIME AUCTiOMS 

Technical Field 

The present invention relates to reakime auctions that are conducted in-whole or in-part over a computer 
network, and more particularly, to methods for collecting bids from ronote usot. 
5 Baclcereund of the Inventien 

During the past five years, the Internet has blossomed from a medium for simple data exchange and 
messaging to the fastest growing, most innovative medium for information exchange and commerce. Virtual shopping 
malls, buying services, and other types of Internet-based retailing methods are being employed by an ever increasing 
number of retail merchants. In addition, a number of organizations, including eBay^, provide Internet-based auctions. 

10 Sellers of goods and services register those goods and services with the auction organization, and the auction 
organization then provides information over the Internet about the goods and services to potential bidders. A bidder 
may submit a bid via the Intenmt for a particular good or service to the auction organization. The auction organization 
collects bids over a period of time, after which the auction organcation notifies the highest bidder that the highest 
bidder has submitted the winning bid, notifies the seller of the identity of the winning bidder, and provides for an 

15 exchange of information between the seller and the winning bidder for execution of the transaction. This type of 
auction is known as a 'silent auction.' 

With the rapid rise in popularity of Internet commerce and information services, and the rapid evolution of 
computer and communications technologies, great strides have been made in improving the timeliness, quality, 
quantity, and, perhaps most importantly, the types of information that can be exchanged through the Internet. 

20 Whereas ten years ego, the Internet wes primarily used for file transfer and exchange of text-based messages, today 
the Internet is routinely used for distributing elaborate, interactive, real time graphical displays, reakime audio, and 
real-time video. These technological Improvements greatly increase the user appeal of Internet-based silent auctions. 
The technological iroiovations also provide a basis for more interesting and more interacth/e Internet-based auction 
models. For example, it would be desirable to conduct five auctions over the Internet 

25 Distrbution of a real-time, live auction is far more complex and technologically demanding than carrying out a 

silent auction over tiie Internet. Real-time Hve auctions are generally conducted by auctioneers in front of a live 
audience. Auctions are fast-paced, and bids may be submitted by very concise gestures or vocal signals. The auction 
of a siiqte item may transpire in a very short interval of time, often as brief as ten seconds. Thus, real-time, Ih^e 
auctions require careful and quick monitoring and intraaction with the auction process. 

30 Real-time, Kve auctions comprise the auctionmg of a sequence of lots. A lot may be a simple lot, composed 

of single good or service, or a choice or quantity lot, comprising a collection of goods and services that are auctioned 
together. GeneraOy, a sequential inventory of the lots to be auctioned is prepared in advance and distributed to 
potential bUders in the form of a catalogue. However, the auctioneer generally has the discretion to change the 
sequence of lots during the auction, divide choice or quantity lots into smaller lots, or coalesce smaller lots into larger 
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lots. Thus, during 8 live auction event a bidder must monitor and quickly bid on a desired lot« while simultaneously 
tracking any changes in the sequence or groupings of goods and services offered. 

There are a number of different types of auction styles. Yankee auctions begin with a low asking price, 
which is increased during the auction with each successful bid. Dutch auctions, by contrast, start with a high price 
5 that is decreased incrementally by the auctioneer until the auctionror obtains a first winning faii 

There are (Efferent types of lots, as nmntioned above. Choice lots include a collection of goods or services. 
The auctioneer initiates bidding on a choice lot on a per-iton price basis, eventually establishing a price point The high 
bidder may select which items he or she wants from the inventory at that price point. The auctioneer offers the 
rmaining inventory to the floor at the price*point value. If any items in the lot remain unsold, the auctioneer has the 

10 option of re-initiating bidding on a new lot comprising the unsold items, or passing and moving on to the next lot. 
Quantity lots comprise many identical items. As with choice lots, quantity lots involve establishing price points, 
although these price points typicaOy have minimum quantities associated with them The auctioneer first establishes a 
minimum quantity for a quantity lot, and then initiates bidding to establish a per-item price point. The high bidder may 
select the minimum quantity or may select more items at that price point The auctioneer offers the remaining 

1 5 inventory to the floor at that minimum quantity and price point. If any inventory remains, the auctioneer establishes a 
new minimum quantity for the quantity lot and then again initiates bidding to estaUtsh a per-it&n price point. The 
price points in quantity lots typically decrease as the nnntmum quantity constraint increases, allowing the auctioneer 
to sell small numbers of units et retail-lie vahies and large numbers of units at wholesale-like values within the same 
lot A particular advantage to distributing a live auction over a communications medium, such as the Internet, is that 

20 by bringing many thousands of Internet bidders to the auction, virtual holders can have a huge impact on quantity tot 
pricing, with a far greater percentage of the inventory bid for and sold at retalMike values than at a conventional live 
event. 

Real-time, live auctions have far greater entertainment value, and may be more efficient in time, than the 
silent auctions currently conducted over die Internet. However, for real-time, live auctions to be distributed over tite 

25 Internet Internet-based solutions and methodologies must be devised to overcome the many complex problems 
associated with real time, live auctions. In particular, an htemet based facility for distribution of real-time, Ihre 
auctions to reniote bidders over the Internet or a similar communications medium, must address the following 
problems: (1) a need for real-time monitoring and interaction with the auctioneer and auction audience; (2) a need for 
repidly disseminating status information from the live aiction, in reel-time, to remote bidders; (3) a need for rapidly end 

30 efficiently collecting bids from remote bidders and presenting those bids to the auctioneer; (4) a need for authorizing 
and verifying remote bidders' identities; and (5) a need for quickly determining any changes in the sequence of lots and 
tot assignments that occur dtffing tfie course of a live auction and distributing information about the changes to remote 
bidders. 
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Summary of the Invention 

The present invention provides an architecture and associated method for processing ntessage diata 
associated with a real time auction. An auction server maintains a state of one or more real time auctions based on 
bids submitted by users, including remote users that subnrit bids via a computer network. The auction server sends 
5 information about the state of one or more auctions to nodes that are coupled betwe^ auction server and tha remote 
users. The nodes use such information to filter out invalid bid submissions, such as those in which the submitted bid 
price does not exceed the current high bid, or for which the auction or lot number Is invalid. The nodes thereby reduce 
the processing load on the auction server by blocking messages that need not be processed by the auction server. 

In a preferred embodmrtent. the invention is incorporated into a system for allowing remote bidders to 

10 participate in live auctions that are conducted by a live auctioneer in the presence of an audience of bidders. The 
system consists of four primary modules: a cBrat program running on a remote computer, a network of 
collector/redistributor nodes runnmg on the broadcaster's enterprise backbone, an auction server process associatml 
with a database where auction state and persistent data are stored, and an auction console that resides at the site of 
the live event, allowing a proxy to introduce remote bids on the floor and report status back to the remote audience. 

15 Each remote bidder interacts with a client program running on a remote computer. The client program allows 

the remote bidder to log into the distribute live auction (DLA") system in order to register as a r«note bidd^ for a 
particular live auction. At the time that the live auction is conducted, the remote bidder interacts with the client 
program on the remote computer in order to follow the course of the real-time, live auction; and to submit bids. The 
remote bidder receives status updates concerning the bidding, tot state, and lot ^quencing from the live auction via a 

20 graphical user interface provided on the remote computer by the client program, and may interact with the graphical 
user interface in order to submit bids for a particular lot 

The collector/redistributor nodes are prefs-ably heirarchically interconnected and serve to efficently collect 
and filter bids from a large number of remote bidders and pass potentially winning bids onto the auction server, and 
also serve to eff eciently broadcast status messages concerning the live auction received from the auction server to a 

25 large number of renmte cBent programs running on remote computers. 

The auction server is a centralized connection point that interconnects collector/redistributor nodes, on-site 
auction consoles, and a database that computationally mirrors the states of one or more ihre auctions and that stores 
detailed infomiation about both on-going and upcoming auctions. The auction servo' is the focal point for collecting 
bids from remote bidders and for distributing status information about one or more concurrent live auctions to remote 

30 bidders. Moreover, the auction server manages extoisive information about current and future auctions, including 
detailed inventory lists and lot assignments. The auction server is directly connected to root-level 
collector/redistributor nodes and is also connected, via the Internet, to one or more auction consoles. 

The auction console is a program running on a computer, often a laptop computer, that interacts with a 
human proxy in the audience of the live auction. The human proxy is notified of bids from remote bidders via the 

35 auction console program and may submit bids to the auctioneer durmg tiie auction process. The human proxy monitors 
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the auction, reports changes in the state, such as successful bids or sales, as well as changes in the lot sequence or 
assignments via the auction console program to the auction server. 

The DLA solves the problems associated with distributing a reaMime, live auction using a combination of 
technologies, communications protocols, software programs, human proxies, centraliied databases, and auction 
5 management methodologies. In particular, the human proxy is able to monitor and interact with the auction process in 
real-time, as well as monitor and report changes in lot sequences and assignments. The DLA architecture provides an 
efficient extremely fast medium for distributing status information about an auction to a large number of remote 
bidders and for coliectng bids frmn remote bidders and presenting them to the auctioneer. The present system thus 
provides a method for bringing the excitement and time efficiency of a live auction to remote bidders over the Internet 
10 Brief DBscrintion of the Prawinnf 

Figures 1-2 are state transition diagrams illustrating a silent auction and a real-time, live auction, 
respectively. 

Figure 3 illustrates the DLA methodology for implememing Internet-based live auctions. 

Hgure 4 illustrates the basic system architecture of the DLA that enables rapid, real-time provision of auction 
1 5 status information to remote bidders and rapid, real-time provision of remote bids from remote bidders to an DLA 
human proxy attending a live auction. 

Figures 5-8 illustrate the basic client/OLA transactions of the DLA transaction modeL 

Figure 9 is a representation of the graphical user interface displayed to the OLA human proxy by the DLA 
auction console program. 

20 Figure 1 0 straws the contenU of the status message generated by the DLA auction console. 

Figure 1 1 shows the bid message generated by the DLA client program during a live auction. 
Figure 12 is a blocked diagram of the DLA client pro-am 

Figure 13 is a flow control diagram of that portion of the OLA client program concerned with supporting and 
facilitating a client's participation in a live auction. 
25 Figure 14 is a blocked diegram of a collect/redistributor node. 

Hgure 15 is a flow control diagram that portion of the collector/redistributor node related to carrying out one 
or more simultaneous Sve auctions over the Internet via the DLA client program. 
Figure 16 is a flow control diagram for the routine "process status." 
Figure 17 is a blocked diagram of the DLA auction server program. 
30 Figure 18 is a flow control diagram for that portion of the DLA auction server program involved in 

nnpiementing Internet-based live auctions. 

Figure 19 is flow control program diagram of the routine "bid." 
Figure 20 is a flow control program diagram of the routine "sync" 
Figure 21 is a block diagram of the DLA auction console program. 
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Figure 22 is a flow control diagram in that portion of the OLA auction console program concerned with 
facilitating a live auction. 

Detailed Doscription of a Preferred Embodiment 

The preferred embodiment will be described in three subsections that follow. In the first subsection, state 
5 transition diagrams are used to illustrate and contrast the silent auction model and the real-time, live auction model. 
The overall architecture of the Internet-enabled Distributed Live Auction (DLA") system is also presented in the first 
subsection. In the second subsection, the user interface provided to a remote bidder by the DLA is described, along 
with descriptions of messages passed between the cHent program and the OLA. h the third subsection, four basic 
types of components of the OLA are described using both block diagrams and flow control diagrams. 

10 Auction State Diaorams and OLA Architecture 

Figures 1-2 are state transition diagram illustrating a silent auction and a real time, live auction, respectively. 
In Figures 1 and Z states are represented by labeled ovals, such labeled oval 102 in Figure 1, and state transitions are 
represented by directed line segments, such as directed line segment 104 in Figure 1. In both Figures 1 and Figure 2, 
state transition diagram ftsr the r^tstration and auctioning of a single lot are shown. 

15 In Figure 1, a lot enters the "lot registered" state 102 through a registration transition 103. The lot may be 

registered by a seller through an interactive Internet-based web page, by mail, by telephone, or by some other 
communications means. A lot transitions, via transition 106, from the lot registered state 102 to the state is active 
105 when the silent auction organization broadcasts, or makes available, the lot for bidding. While in the active state, 
bids may be submitted for the lot by remote bidders via transition 107. In Hgure 1, two differmit transitions 108-109 

20 are shown leading from the active state 105 to the inactive state 110. A transition from the active state to the 
inactive state may occur upon the expiration of a defined bidding period or, in oxhm words, via a timeout 108. Under 
some silent auction models, other transitions from the acthre state 105 to the inactive state 110 may be possible, 
including receipt of a bid that meets some desired price via transition 109. From the inacthre state, transitions lead to 
the active state 105, the state "sold" 111, the state "finish" 112, and the lot registered state 10Z If no bids that 

25 meet some minimum pr^ are receved wh3e tte lot is in the acthre state 105, then, following transition to the inactive 
state 110, the lot may transition to the finish state via transition 113 when no provision been made to 
automatically re-register the lot. Alternatively, the lot may transition to the lot registered state 102 via transition 114 
when a provision has been made to automatically re-register the lot Similarly, there may be an automatic provision to 
resubmit a tot that has not yet received a sufficient hid back to the active state 105 via transition 115 for an 

30 additional period of time. If one or more sufficient bids are received for tiie lot while the lot is in the active state 105, 
then, following transition to the inactive state 1 10, the lot transitions via transition 116 to the sold state 111. If the 
lot contains only a single item or service, or the winning bidder chooses all the items in the lot then the lot transitions 
from tin sold state 1 1 1 to the finish state 112 via transition 117. If, on the other hand, there are more items in the 
lot not chosen by tiie winning bidder, then the lot may transition either back to the acthre state 105 via transition 1 18 

35 or back to the lot registered state 102 via transition 104. A ghren silent auction implementation may include more or 
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fewer states than the number of states shown in Figure 1, and may include either more or fewer state transitions than 
the state transitions shown in Figure 1. Hgure 1 is intended to illustrate the states inhabited by a lot during a 
generalized silent auction. 

Certain features of the state transition diagram shown in Rgure 1 provide for relatively easy finplementations 
of Internet-based silent auction systems. Foremost among these features is the relatively limited and non-time critical 
transitions available to a lot once the lot first reaches the active state 105. The lot may transition out of the acthre 
state 105 either foDowing expiration of a timer or following submission of a sufficiently high Ud. Note that, in specific 
implonentations of sient auction systems, additional transitions may be possible. However, in all cases, the nature of 
these transitions leaves a vary long window of opportunity for any particular remote bidder. In addition, a remote 
bidder need not know about the presence of other remote bidders or about their participation in the sOent auction. If 
the silent auction system displays the highest bid received, the remote bidder may check back from time to time, over 
a period of days, to monitor progress in the bidding, or may be notified by email that they have been outbid, and may 
then submit a subsequent bid. 

In the silent auction, a large number of different lots may concurrently inhabit each of the different states. 
For example, many hundreds of different lots may be concurrently active for bidding. B^ause of this, the ronote 
bidder does not need to constamly and rapidly mtmitor changes in the sequence of the auction or in lot assignments. 
AH the items offered for auction can be viewed by a remote bidder during the course of the auction, and bids can be 
rationally submitted for those lots of interest to the remote bidder without concern for items being reassigned to 
different lots or the sequence of lots offered for auction being changed. 

Figure 2 shows a representative state transition diagram for a lot in a real-time, live auction. As in Rgure 1, 
a lot enters the state "lot registered" 202 via a registration transition 204. The tot may be registered by the auction 
house or auctioneer via Internet-based methods, or by additional communications methods, inchiding telephone, 
mailings, and fax. At some specified time interval, the lot transitions to either the state "pre bid" 206 via transition 
208 or to the >en for bidding" state 210 via transition 212. In the pre-bid state, preliminary bids are accepted for 
the lot, prior to the lot becoming acthre during the auction, from remote bidders via transition 214. These pre-bids 
trigger the activation of a bidiGng agent that automatically produces bids after the lot transitions to the state ''open 
for bidding''210, ifiscussed below, until either the pre-bidder wins, or the high bid exceeds the pre-bidder's bid value. 
After another interval of time, the lot transitimis from tl» pre-bid state either to the open-for bidding state 210 via 
transition 216 or to the state "pass*" 218 via transition 220. The pass state represents the state of a lot that has 
likely been withdrawn from bidding by the seller, in the case of transition 220. A reason for transition 220 is that the 
submtned pre-bids are insufficient to warrant placing the lot up for auction. From the pass state 218 the tot may 
either transition back to the lot registered state 202 via transition 222, in the case that withdrawn lots are 
autmnatically rescheduled, or may transition to the state "finish' 224 via transition 226 in the case that withdrawn 
lots are removed from further consideration. Other transitions from the pass state 218 may be possible in particular 
implementations, including automatic transitions (not shown) back to the pre-bid 214 and open-for-btdding 210 states. 
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Once a lot transitions to the open-for-bldding state 210, real-time bids are solicited for the lot by a live auctioneer. 
Only a single lot can inhabit the open-for bidding state at given time in a live auction. That is also true for the 
remaining states in the state transition ifiagram, including the state "presold" 226, the state "fair warning" 228, the 
state iast chance* 230, the state "sold" 232, and the state Invemory reduction' 233. 
S From the open-for-bidding state 210, the lot may transition via transitions 234 and 236 to the pass state 

218, in the case that no bid, or no sufficiem bid, is received after some period of time. During the period of time, 
insufficient bids can be received via transition 238. When a sufficient bid, i.e. a bid equal to or exceading some 
minimum desired value, is obtained, the lot transitions via transition 240 to the presold state 226. A lot in the presold 
state will be sold to the current highest bidder unless a higher bid is received within some time interval. Additional 

10 higher bids may be accepted for the lot while the lot inhabits the presoU state 226 via transition 242. If no further 
bids are recehred dursig some time mterval, then the lot transitions from the presold state 226 to the fair warning 
state 228 via transition 244. If a higher bid is received for the lot while it is in the fair warning state 228, then the lot 
transitions from the fair warning state 228 via transition 246 back to the presold state 226. On the other hand, if no 
higher bid is received for the lot while it resides in the fair warning state 228, then the lot transitions via transition 

15 248 to the last chance state 230. If a higher bid is received for the lot while the lot inhabits the iast chance state 
230, the lot transitions back to the presold state 226 via transition 250. However, if no higher bid is received for the 
tot while the tot inhabits the last chance state 230, then the lot transittons from the last chance state 230 via 
transition 252 to the sold state 23Z If there are no more items in the lot, then the lot traiotttons from the sold state 
232 via transition 254 to the finish state 254. If, on the other hand there are items remainmg in the tot that were not 

20 sold to the first winning bidd^, then the lot transttons via transition 256 to the inventory-reduction state 233, in 
which other bidders may purchase items from the lot at the current bid price. If unsold items remain after a period of 
time, the lot containing those unsold items may transition, via transition 257, back to the open-for-bidding state 21 0. 

The additional complexities involved in implementing an Internet-based live auction, in contrast to 
implementing the silent auction illustrated in Figure 1, are readily apparent in the state transition diagran of Figure 2. 

25 First there are far more states that may be inhabited by a lot while the lot is being auctioned in real-time. These 
active states include: (1) open-for bidding 210; (2) presold 226; (3) fair warning 228; (4) last chance 230; (5) sold 232; 
and (6) inventory reductton 233. There are a correspondingly larger number of state transitions possibto for a tot that 
is being auctioned in real-time. Thus, the overall complexity of the process is greater. More importantly, as mentioned 
above, a lot may traverse tte various active states in relathrely short periods of time, on the order of tens of seconds. 

30 Thus, a relatively large amount of state infomration concerning a lot must be transferred to remote bidders at 
extremely rapid rates. Delays on the order of seconds may seriously inhibit a remote bidder's ability to effectively 
participate in the live auctton. As mentioned above, only a single tot can be in any of the active states at any instant 
of time during the action process period. Thus, the remote bidders must be rapidly notified of changes in lot sequences 
and tot assignments in order to intelligently participate in the bidding. For example, if a complex tot has been dhrided 

35 by the auctioneer during the auction, and a remote bidder is mterested in purchasing a single item from the original 
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complex lot, the remote bidder nrads to aware that the remote bidder may have a second chance to bid on the desired 
item later In auction, following auction of the first of the divided lots, in order to avoid bidding too aggressively for the 
first of the dhrided lots. Thus, not only must a large amount of status information concerning the state of a given lot 
be distributed to remote bidders, but a large amount of additional information concerning lot re-sequencing and 
reassignment must also be imparted to remote bidders in real time. A reader skilled In the art of implementing Internet- 
based commerce media will appreciate that implementation of internet-based live auctions involves a far more complex 
and technologicafly demanding solution than implementation of the silent auction model diagrammed in Rgure 1 and 
discussed above. 

Figure 3 illustrates, at a high level, the DLA methodology for implementing Internet-based live auctions. The 
live auction occurs in front of a live audience of bidders 302. The auction is conducted by one or more auctioneers 
304. A DLA human proxy 30B is also present within the in-person audience of bidders. The DLA human proxy 306 
monhors the auction, including bids made by in-person bidders as well as statements made by the auctioneer 304, end 
enters the bids and statements into the OLA auction console running on a computer system 308. In a preferred 
embodhnent, a laptop PC may be used to run the OLA auction console for reasons of ease of use and portability. The 
information regarding the status of the auction entered by the OLA human proxy 306 into the OLA auction console 
running on the computer 308 is transfenr^l via the Internet 310 to the DLA auction server 31Z 

The DLA auction server 312 may be implemented on one or more high-end server PCs, workstations, mini- 
computers, or mainframes. The OLA auction server 312 incorporates the incoming status information from the DLA 
human proxy 306 into a database representation of the instantaneous state of the auction, and, at the same time, 
broadcasts status updates via the Internet 314 to a number of ranote bidders 316-319. The remote bidd^ 316-319 
monitor the live auction via the status information broadcast from the DLA auction server 312, and may also listen to 
the auction via real-time audio broadcast of the Eve auction or watch the auction via real-time video broadcast of the 
five auction captured by one or more recording devices (not shown) and transmitted to the remote bidders via the 
Internet or possibly through other communications media, including cable TV and radio. The remote bidders may 
submit bids for particular items in real-time, just as if they were present, in-person, in the audience 302. 

Remote bidders submit a bid via the DLA client program running on the remote bidders' computer system, for 
example computer system 320, which are then transmitted via the Internet 314 to the auction server 311 Remote 
bids are filtered and verified by the DLA systan so that ordy valid bids from authorized remote bidders are transmitted 
by the DW auction server 312 to the DLA human proxy 306 via the Internet 310 and the DLA auction consote running 
the DLA human proxy's computer OLA 308. Upon recehring a remote bid from a remote bidder, the OLA human proxy 
308 may then interact with the auctioneer 304 to submit the bid. If the bid is accepted, that fact like any other 
status information concerning the Eve auction, is submitted by the DLA human proxy 306 via the DLA auction console 
running on the DLA human proxy's computer 308 and the Internet 310 to the DLA auction server 312 for subsequent 
broadcast to the remote bidders 316-319. In order for the remote bidders to effectively particqiate in the live euction, 
the remote bidders need to receive status updates from the live auction in time periods on the order of a second or less. 
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and, in the same time interval need to be able to submit bids that appear on the DLA auction console running on the 
DLA human proxy's computer 308. 

Figure 4 illustrates the basic system architecture of the DLA that enables rapid real-time provision of auction 
status information to remote bidders and rapid, real time provision of remote bids from remote bidders to the DLA 
human proxy attending the live auction. As mentioned above, the DLA auction console program runs on a computer 
402 located on-site at the live auction. The DLA auction console program communicates with the OLA auction server 
program that runs on one or more server computers 404 via the Internet 406. The DLA auction server program stores 
and retrieves data frwn a centralized database 406. The c&itralized database 406 contains information about ongdng 
and upcoming auctions, including detailed status information that provides a computational snapshot in time of the 
state of all ongoing auctions, as well as information related to the lot inventories and lot sojuencing for both ongoing 
and upcoming auctions. 

Many thousands or hundreds of thousands of remote bidders may participate in a given auction. The DLA 
must therefore incorporate technology to enable status information concerning an ongoing auction to be broadcast, in 
real time, to the remote bidders and to enable bids to be transmitted from the remote bidders, in real-time, to the 
auction console program running as the on-site computer 402. The preferred embodiment for this technology is 
ilustrated in Figure 4. The auction server program running on the server computer 404 is directly interconnected via a 
communications network 410 to a number of root-level collector/redistributor nodes 412 and 414. Although only two 
root-level collector/redistributor nodes are shown in Figure 4, the euctton server program, as currently implemented, 
may be interconnected dir«:tly with up to ten route-level collector/redistributor nodes. Each rooMevel redistributor 
node, for example collectorfredistributor node 412, is connected via a communications network, for example 
communications network 414, to a next-lowerlevel set of collector/redistributor nodes, for example 
collector/redistributor nodes 418 and 420. In Figure 4, only two levels of cdlector/ redistributor nodes are shown. In 
a functioning DLA system, a sufficient number of collector/redistributor node levels are dynamically configured in order 
to support an arbitrary number of connected remote bidders. The hierarchical fan out of levels of 
collector/redistributor nodes provides for rapid, concurrent distribution of information to remote bidder computers and 
rapid filtering and collection of bids from remote bidcter computers. The leaf-level collector/redistributor nodes, called 
*first-line nodes' 418, 420, 422, 424. each supports a large number of connections via the internet 426 to a large 
number of remote bidders' computers, such as remote bidders* computers 428437. A first-line collector/redistributor 
node may be concurrently connected to up to 200 remote bidders' computers in a preferred embodiment The 
collector/redistributor nodes and the server computer 404 are interconnected by high-speed networic communications 
410 and 416. Thus, status information may travel from the on-site computer 402 to a rmiote bidders' computer, for 
example remote bidders* computer 428, via an initial Internet connection 406, a series of high-speed communications 
network transfers 410 and 416, and a second connection 440. The TCP/IP connections of the collector/redistributor 
nodes are multiplexed through a single port using a multiplexer, because serially sending status infomnation to remote 
biddo's' computers via one or a small number of processes from the server computer 404 would be far too slow for the 
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purposes of informed remote bidder panidpation in the live auction. Similarly, the hierarchical interconnection of 
collector/redistributor nodes allows for filtering bids, using a variety of criteria, including lot and auction ID verification, 
bid value, and various bid inventory checks. The bid inventory checks include checks to make sure that there is 
sufficient Inventory available for a particular bid and to make sure the bid meets minimum inventory requirements 
5 estabii^ed on the floor by the auctioneer, e.g. minimum quantities in quantity lots. Only valid bids with the highest 
detected bul prices submitted by the remote bidders* computers connoted to a particular collector/redistributor node 
are propagated back towards the server computer 404. This greatly reduces networic traffic and message handling in 
upstream collector/redistributor nodes, the server computer 404, end the on-site computer 402. 

DLA Transaction Model 

10 Figures 5-8 illustrate the basic client/DLA transaction model. Figures 5-8 are divided into columns, such as 

columns 502 and 504 h Figure 5. The left-hand columns, such as column 502, represent the transaction from the 
client's perspective, and the right-hand columns, for example column 504, represents the transaction from the 
standpoint of the DLA. Right-handml arrows, such as right-handed arrow 506, represent the sending of a message 
from a client to the DLA via the Internet. Left-handed arrows, such as teft-handed arrow 508, represent the sending of 

15 a message from the DLA to the client via the Internet. The arrows in Figures 5-8, both right-handed and left-hand«l, 
may be considered to be a sequence of steps within the transaction described in the figure. 

Rgure 5 illustrates the client registration transaction. In a first step 506, a prospective client requests a 
client registretton screen from the DLA in order to commence the client registration transactum This request may be 
made, for example, by cOcktng on a hyperiink within an OLA web page or Internet search-provider results paga In step 

20 SOB, the DLA returns the registration screen 510. Note that in Figures 5-8, simpKfied representations of various 
transaction screens are shown as representative examples of the nature of the information requested and cfisplayed. 
In general, these screens may contain a greater amount of information, or may be Hnplemented as an interactive 
dialogue, or may alternatively be coalesced into fewer scrrans or pages or may comprise a greater number of screens 
or pages. The simplified screens of Figures 5-8 are provided for illustrative purposes and represent e generalized data 

25 collection or data dsplay process. The first registration screen 510 includes text entry boxes for the user to select a 
user ID and password with which to subsequently login to the DLA system. Alternatively, the user ID end password 
may be g^erated by the OLA based on information provided in subsequent screens shown in Figure 5, thus obviating 
the first exchange in Hgure 5 comprising steps 506 and 508. In step 512, the prospecthre client supples a chosm 
user ID end password to the DLA by typing the mformation into tiie text «itry fields of first registration screen 510 

30 and indicating, by clicking a push button or by soma other indication, that the infomiation should be returned to tiie 
OLA. Alternative data entry devices may also be displayed, including selection lists or buttons. In st^ 514, the DLA 
returns a second registration screen 518 containing text entry fields for input of adcfitional information concerning tte 
prospective client This information may inchide the prospective client's name and address, for example. In step 518, 
the prospecthra cient filis out the second registration form 518 and returns it to the DLA. In optionei step 520, the 

35 OLA may elect to request additional infomiation from the prosprcthre cfient via a third registration screen 522. Step 
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520 is optional in that all pertinent information may be acquired by the OLA via a single screen. On the other hand, 
additional optional steps, such as step 520, may be necessary to collect further information in other cases. Additional 
information may include credit card numbers, bank accoimt numbers, employer names and addresses, phone numbers 
and other such information. All the information provided by the client to the OLA will be maintained by the OLA in one 
or more databases. The DLA can then use the stored information to faclKtate the client's subsequent registration for 
particular auctions, to be discussed below. 

in general, the DLA strives to collect a reasonable supvset of Information during the registration process 
commonly required by various auction houses and auction management organizations. By collecting the information 
initialiy, and saving the information, the DLA can then automatically retrieve the stored information and supply 
retrieved information to auction houses and auction management organizations when the client subsequently registers 
a particular auction. Subsequent auction registrations may require certain specialized information particular to a 
particular auction house or auction management organization, or may require updates or moiBfications of information 
originally supplied by the client during the registration process. 

In step 524, the dient finishes entering the requested information into the text entry fields of the data 
collection screen 522 and indicates, via a push button click or some other Indication technique, that the information 
should be returned to the OLA. In step 526, the OLA sends terms and conditions information that is (fisplayed to the 
client in a temis and conditions screen 528. The terms and conditions screen represents an agreement, or contract 
between the prospective dtent and the OLA, to which the prospective dient can either agree or disagree by dicking on 
an appropriate user mterface object. The prospecthre cEent then, in step 528, returns the prospective dient's 
egreement or disagresnent to the terms and conditions to the DLA. 

There are many altemathre steps that may occur in the registration transaction depending on the prospective 
dient's responses. For example, if the client disagrees with the terms and conditions, the OLA may return a screen 
mdicating that the prospective citent has not been accepted for registration with the DLA. bi the case the dient agrees 
witii the terms and conditions, the OLA may return information displayed to tiie client in additional screens tiuit 
indicate that the OLA has registored the prospective client as an OLA dient and addtional informational screens 
showing the OLA dient how to best use the DLA system. Further back in the transaction, the DLA may short circuit a 
number of steps and reject a prospective client if the credit inforniation, for example, is not verifiable or is madequate. 
finally, at tfie completion of the registration process, tfie DLA may download tfie DLA dient program to the new DLA 
client's computer to allow the dient to subsequendy interact with the OLA. 

figure 6 illustrates the dient auction registration transaction. bi fqure 6-8, the user interface screens 
dlsplay«l in tiie dient columns may be generated by the OLA client program running on the client's computer system, 
using, where appropriate, information transferred from the DLA to the OLA cfient program via the Internet 
Alternatively, in some cases, die user interface screens may be prepared by the DLA and sent to the DLA client 
program via the Internet In step 602, the cEent requests an auction list screen from tiie DLA via input to the user 
interface displayed to the dient by the DIA dient program. In step 604. auction list information is returned by the 
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OLA to the client and displayed to the client in an auction Bst screen 606. If there are many upcoming auctions, 
multiple auction list screois may be displayed, or the client may interact with the user interface dtsplayed by the DLA 
client program to navigate through a hierarchical list of categories for items auctioned in particular auctions in order to 
arrive at a sub-list of auctions of interest to the client. Altmatively. the client may select other types of sub-lisu of 
upcoming auctions based on the auction data, type of auction, or other such characteristics. 

Each auction listed in the list of auctions displayed to the client 606 is associated with a status. Different 
types of statuses include: It) 'sign up," a status indicating that the client has not yet attonpted to register for the 
particular auction; (2) "approved," a status indicating that the client has successfully registered for the auction; (3) 
"denied," a status indicating that the client has attempted to register for the auction, but was doiiad registration for 
one of various reasons, including inadequate credit or failure to agree to terms and conditions; and (4) "waiting/ a 
status incficating that the client attempted to register for the auction and that DLA has y«t to respond with an approval 
or denial. 

In step 608, the client selects an auction and indicates that the client wishes to attonpt to register or re- 
register for a particular auction by clicking on the status associated with the auction. In step 610, the OLA may then 
return a data collection screen 612 requesting any additional or particularized information needed from the dient in 
order to register the client for the selected auction. In step 614, the dioit fills in the requested information into text 
mtry fields, or alternatively, selects various alternatives via user interface sdection objects, and returns the 
infonnation to the DLA. In step 616, the OLA may return a special terms and conditions form to a dient for the 
selected auction, to which the client may agree or disagree in step 618. The exchanges represented by steps 1610 
and 1614 and by steps 161 6 and 1618 may not be necessary in many cases. It may often be tfie case that the dient 
provides sufficient information in the registration process so that the OLA may automatically retrieve the previously 
submitted infonnation from the OLA database and furnish that information to the auction house or auction 
management organization. Similariy, the initial temns and conditions agreemoit made by the cSent during the 
registration process may be sufficient for a large number of auction houses or auction management organizations, thus 
obviating the need f« a specialized or particularized terms and conditions step related to a particular auction. In stqi 
620, the DLA client program redispiaYS the list of auctions 622 previously dtsplayed in screen 606, updated with new 
or additional status infonnation provided to the DLA client program by the DLA. For example, the client request for 
^'5^8^'°f! j?'' ?f! ?"ction '"ay Quickly approved, resulting in the status for that auction being displayed as 
"approved," rather than as "sign-up" or "denied." Them may be additional steps in altemative embodnnents and 
implementations of the dient auction registration transaction, and additional outcomes for each step depending on 
infonnation si^plied by the dient to the OLA. 

Figure 7 ilhistrates tiie client inventory browsing transaction. As bi Figure 6, the client miuests, in step 702 
and recehres, in step 704, information from the OLA that is displayed by the DLA dient program to the dient as an 
auction Est. In step 706, tiie climt sdects, from die auction list, a particular auction and indicates, via a user 
interface indcation object, a desire to examine tiie inventory of lots being offered for sale in the selected auction. In 
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Step 708, the OLA returns a list of categories of lots to be offered for sale in a selected auction. The categories may 
list types of goods or services, in the case of simple or quantity lots« or may include a more elaborate, hierarchical 
listing, in the case of complex lots. The list of categories of lots are displayed to the user in a disptey screen 710. In 
step 712, the client selects particular categories of lots and returns the selection to the DLA. In step 714, the OLA 
5 returns a list of lots pertaining to the selected category displayed to the user via screen 716 by the DLA client 
program. From this list of lots, the client selects a particular lot and returns the selection to the OLA in step 718. In 
step 720, the OLA returns a description the lot to the OLA dient program, which then displays textual, graphical, or a 
combination of textual and graphical information concerning the selected lot to the client in an informational screen 
72Z The informational screen 722 may include a user interface object allowing the client to indicate a desire to 

10 submit a pre-bid for the selected lot. If the client selects to pre-bid on the lot, the client returns the indication for a 
desire to pre-bid on the lot to the OLA in step 722. In response, the OLA returns information concerning the pre-bid 
state of the lot to the DLA cGent progran, which displays the information in a pre-bid screen 728 to the client The 
pre-bid screen 726 allows the client to enter information, including a bid price, to return to the DLA in step 728. 
Additional navigational user interface objects allow the client to navigate back to the auction list and select a different 

15 category, or to navigate back to the list of lots or to the informational screen 722. Thus, the client is able to browse 
through the inventory of lots to be offered for sale at a particular auction, and to pre-bid on those lots offering a pre- 
bid option. 

Figure 8 illustrates client participation in a live auction. A client requests of list of ongoing auctions from the 
OLA in step 802, and the OLA returns the requested information in step 804 to the DLA client program which then 

20 displays a list of ongoing auctions to the client in a list of auctions screen 806. As in Hgures 6 and 7, the exchange 
represented by steps 802 and 804 may involve additional sub-exchanges of information in orcter to retrieve sub-lists of 
ongoing auctions according to various categories selected by the cfient In step 808, the dient selects an auction from 
the list of auctions and indicates via a user interface object that the dient wishes to join that auction. Once the DLA 
has verified the client's prior registration for the auction, or alternathrely, conducts an auction registration dialogue 

25 with the cfient, the DLA client program displays an auction status screen 808 and the dient is continuously updated by 
status information received from the OLA auction console via the DLA auction server program in steps 810, 812, and 
814. The status information messages are received by the DLA dient program from the DLA as frequently as the 
status of the live auction is updated by the OLA human proxy's manipulation of the OLA auction console user interface, 
or as fast as automatic status updates are generated by incoming Internet bids. The client's auction status screen is 

30 continuously being updated to reflect tha new asking price. If tin remote bidder using the DLA client program wishes 
to submit a bid, he or she clicks a bid button 818, resulting m submission of a bid whose value is equhralent to the 
current askiiig price displayed on the dient's auction status screen. Once the bid button 818 is cBcked, the DLA dient 
program sends a bid message via the Internet to a front-line collector /roiistributor node in step 820. The bid is 
filtered through the DLA and may end up displayed to the OLA human proxy on the DLA auction console. If the dient's 

35 bid is presented by the DLA human proxy and accepted by the auctioneer, that acceptance will be reflected to the 
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client by subsequent update of the auction status screen 808 via reception by the DLA client program of a subsequent 
status message from the DLA. If the client's bid is a winning bid, then the client's auction registration mformation is 
submitted to the auction house or auction management organization, and the client is notified via the action status 
screen 808, and additionally notified by other communications metiiods including e^nail, a telephone call, or some 
other method. Note tiiat the client who submits a winning bid is contractually bound to submit payment for the good 
or service, just as a member of tiie audience present at the site of the Ihre auction is bound to honor a winning bil 

Figure 9 is a representation of the user interface displayed to tiie OLA human proxy by the DLA auction 
console program. This user interface must provide simple end easily recognixed controls to aOow the DLA human proxy 
to quickly update status information about tiie auction as tiie auction proceeds. Thus, controls m provided to indicate 
the state of the lot, as discussed above with ref^ence to Figure Z as well as to note changes in lot inventory 
sequences and lot assignmoits. 

bi a preferred embodiment, the DLA auction console consists of a Java 1.02 applet running in a web browser, either 
Internet Explorer or Netscape Navigator/Communicator. It maintains a continuous connection witii tiie caitrel auction 
server to transmit and recehre information in real time. The DLA auction console displays tiie user interface shown in 
Figure 9. Certain status messages are displayed in the right hand column 902. These are provided to allow the console 
operator to ensure that tiie correct product is being sold and that the correct information is being passed to the remote 
bidders. Text displayed in red indicates that a remote bidder is currentiy leading. The center of the user interface 
consists of an anay of buttons 906 used to establish a current bid, a bid incrwnent, and an asking bid. These values 
can also be typed in directly. Along the top of the user interface is a group of six buttons, including: "Fair 
Waming'908, "Last Chance-giO, 'Sold' 912, and Tass-914. These buttons are used by the human proxy to set 
specific status flags that are sent to die DLA auction server, and subsequently by the DLA auction server to remote 
bidders, and are also displayed on the right-hand status readout. The button 'Sold Locar918 sets tiie sold status flag 
whh the last recorded value from a local bidder, and the button 'Next Item" 918 indicates to tiie server that the next 
lot number in sequence should be loaded. If an out of-sequence lot is detected by tiie human proxy, the human proxy 
can utilize the text entry field lump to''920 to enter a lot nimiber to teU die DLA auction server to load the description 
and details for a different lot Using die flash text list of buttons arranged in a column 922 on die left of the user 
interface, tiie DU human proxy can choose to send to the DLA auction server informational or flavor text selected 
from a series of canned phrases designated ahead of time by tiie auction house. If none of the cenned phrases are 
appropriate, a text message can be entered and sent by die OLA human proxy using the text aitry field 924. Future 
enhancements win include tfie capabSity to group and re-lot lots, as well as a predictive capability to automatically 
determine the next asking price from current asking price intervals. 

Figure 10 shows the contents of tfie status message genmted by tiie DLA auction console program, and 
Figure 1 1 shows die contents of the bid message generated by die DLA client program. These two messages f omi the 
basis of the real-time information exchange between die DLA human proxy on-site at a live auction end the many 
renrrate bidders participating in a live auction via the Internet. Both tiie status message, 1002, and the bid message 



-14- 



wo 00/39735 



PCT/US99/31061 



1 102, contain lower-level protocol headers and information that allow the messages to be routed through the Internet 
and through high-speed communications networks. The fields in both the status message 1QQ2 and the bid message 
1102 following the low-level protocol information fields 1004 and 1104, respectively, comprise the status and bid 
massages at the OLA lavaL 

The status message contains the following fields: (1) a message identity field 1008 that indicates the type of 
message, in this case, a status message; (2) an auction ID field 1008 contains a unique identifier for the auction to 
which the status message pertains; (3) a lot ID field 1010 that contains a untqtn identifiar for the tot currently bemg 
auctioned at the auction identified by the auction ID identifier in the aucticm ID field 1008; (4) an ask fieU 1012 that 
contains the asking price for the lot identified by the lot ID in the lot ID field 1010; (5) a high bid field 1014 containing 
the highest bid received for the tot identifioi by contents of the tot ID fidd 1010; (6) a high bidder field 1016 that 
indicates the klentity of the bidder who submitted the high bid contained the high bid field 1014, where the high bidder 
may be either a member of the audience present at the live auctton or a remote bidder; (7) a status field 101B that 
contains the current status for tlie lot kientified in the lot ID field 1010, where the different possibte statuses are the 
active statuses illustrated above in Figure 2 and discuss^ above with reference to Hgure 2; (8) e text field that may 
contain additional textual infomratiim supplied by the DLA human proxy with referme to the status of the lot 
identified by the tot 10 contained in lot ID field 1010, or, alternativdy, toformation with regard to status and updates 
concerning the auctton identified by the auction ID contained m tiie auction ID field 1008; and (9) an availabte 
inventory ftold 1022 that descr&es the avaitoble inventory in the lot. Status messages having the illustrated format 
are continuously generated by the DLA auction server program and sent vie the OLA system to remote bidders. 

The bid message 1102 contains the following ftolds: (1) a message identiftor field 1106 text contains an 
indication of the type of tiie message, in tiiis case, a bki message; (2) an auctton ID field 1 108 simitor to the auction ID 
field 1008 of tiie status message 1002; (3) a lot ID ftold 1 1 10 simitor to the tot ID field 1010 of tiie status message 
1002; a bidder ftold 1112 that contams a unique identiftor for the remote identifier that submitted the bid tfiat 
generated the bid message; (5) a bid ftold 1114 that contains the bid price submitted by the bidder and tiie bid tiiat 
generated the bid message and (6) a desired toventory field 1 1 16 tiiat contains the bidcter's desired inventory for a 
composite tot Bid messages are generated by the DLA client program running on remote bidders* computers and sent 
via the DLA systm to the DLA human proxy. 

pi,A $Y«tefftCoinppnBtrtl 
in thto subsection, four basic components of the DLA system, tochiding tiie DLA client program, tfie 
cdtoctor/redistributor node, the DLA auctton server program, and tiie DLA euction console program, wSI be descrflbed to 
btock diagrams and in flow control diagram. These descriptions represent a preferred «nbodlment but by no means 
the singte possibto embodiment of the DLA system. The component software program may be implementad in many 
different ways in many different languages and run on many different types of computers featuring different oprnting 
systems. Functionaiittos encapsulated n one particular component in tiie preferred embodiment may be, to alternate 
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embodiments, implemented in different components. In alternate embodiments, a different number of basic DLA 
components may be employed to implement the DLA auction methodology descrbed above 

Figure 12 is a block diagram of the DLA client program. The DLA client program 1202 mcludes the followmg 
components: (1) A TCP/IP connection manager 1204 that transmits all outgomg messages to the internet and recehres 
5 all incoming messages from the internet; (2) a connectivity manager 1206 that monitors message traffic to detect 
connection failures and that directs reestablishment of failed connections by the TCP/IP cmnection manager 1204; (3) 
an encryption/decryption module 1208 that is called by the TCP/IP coraiection manager to decrypt encrypted incoming 
messages and to encrypt outgoing messages; (4) a user interface module 1210 that manages the display of graplucal 
information, such as the live auction status scrran, to a remote bidd«7 (5) an operating system interface 1212 that 

10 represents the various operating system calls employed by the DLA client program to implement the various 
functionalities supported by the DLA client program; (6) the memory used by the DLA cfient program, including memory 
allocated to various state variables such as the current auction ID and lot iD; and (7) the client process 1216 that 
interconnects the user interface 1210, the OS interface 1212, the TCP/IP connection manager 1204, and memory and 
state variables 1214 to implement the functionafity supported by the DLA client program, such as the client 

15 registration transactions, the client auction registration transactions, client browsir^ of auction inventories, and client 
participation in live auctions, discussed above in the previous subsection. 

Figure 13 is a flow control diagram of that portion of tiie DLA client program concerned with supporting and 
fadlitating a client's participation in a live auctnn. In step 1302, the DLA client program displays to a client the 
euction status screen and then waits for any of a number of different types of events that may occur, if ttie client 

20 submits a bid, as detected by the DLA client program in step 1304, and the DLA dent program paclcages the bid 
information into a bid message and sends the bid message to a first line collector in line/redistributor node in step 
1306, after which the DLA client program resumes waiting for another event. If the DLA client program recehres a 
status message from the DLA auction server, detected in step 1308, the OLA dient program extracts information 
packaged in the status message and uses that information to update the auction status screen display in step 1310, 

25 after which the OLA client program resumes waiting for another event if the DLA client program recehres a request to 
terminate the program, as detected in step 1318, then the portion of the OLA client program related to the 
l»rtidpatum of a cfient in a real-time five auction returns, in step 1320. Otherwise, the DLA cfient program resumes 
waiting for another event 

Figtffe 14 is a bkick diagram of a collector/redistributor node. The cotlector/redistributor node contains the 
30 following subcomponents: (1) a client connection manager 1404 that manages a number of TCP/IP connections to 
rmote bidders, currently capable of handing up to 200 simultaneous TCP/IP connections; (2) a decryption module 
1406 used by the dient collection manager 1404 to decrypt incoming encrypted messages from remote bidders; (3) an 
OS interface 1408 similar in function to the OS interface of the DLA client program (1212 in Figure 12); (4) a database 
interface 1410 that provides storage and retrieval of dient validation information that aOows a first-lina 
35 collector/redistributor node to validate incoming messages from remote bidders with regard to authorization and 
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registration of the remote bidder to participate in a particular auction; (5) a memory and state variable component 
1412 amilar in nature to the memory and state variable component of the OLA client program (1214 in Figure 12); (6) 
an auction server connection manager 1414 that passes filtered fahis from rmote bidders to the next highest-level 
collector/redistrOiutor node, or, in the case of a root-level coiiector/redistributor, to the OLA auction server program, 
and that receives status messages from the OLA auction server program to distribute to remote bidders; and (7| a 
coilectoriredistributor module 1416 that ties together the client cdlection manager 1404, the OS interface 1408, the 
database interface, in the case of a first-line coDector/redistributor, the memory and state variable component 1412, 
and the auction server connection manager 1414 in order to implennent the status distribution operation and remote bid 
filtering and pass-through operation that form the basis of the collector/redistra^utor node functionality related to the 
conduct of a live auction over the htemet 

Figure 15 is a flow control diagram of that portion of the cotlector/redtstributor node related to the carrying 
out of one or more simultaneous live auctions over the bitemet by the OLA. The coilectoriredistributor essentially 
waits, in an endless loop, for one of a number events to occur, and handles each event that occurs. If the 
collector/redistrtbutor is a f o^st-line collector/redstributor, and the collector/redistributor receives a trid message from a 
rmote bidda', as detected in step 1502, the collector/redistributor checks, in step 1504, the auctkin ID and lot ID 
agamst a list of current auctions and their respecthre current lot numbers to determine whether the bid is valid. Also in 
step 1504, the coilector/redistnfautor checks the bid emount contained in the bid field of the bid message against the 
current high bid recehred for the idaitified tot of the idoitified auction. Only if the bid is higher then the current highest 
bid for the identified auction, as detected by the collector/redistributor from bid messages received from other remote 
bidders or from status messages recehred from the OLA euction server, will the collector/redistributor forward the bid 
on to the OLA auction server. If the bid is valid and represents a higher bid, as detected in step 1506, the 
collector/redistributor submits tiie bid to eith^ a next-highest-level collector/redistributor or to the OLA auction server 
in step 1508, after which the collector/redistributor continues to wait for another event. On the other hand, if the bid 
does not pass tfie filter, as detected in step 1506, the collector/redistributor simply resumes waiting for another event 
The collector/redistributor node may employ a hash table containing auction ID, lot ID, and high bid triples in order to 
factlitate rapid filtering of a bid. If the collector/redistributor recehres a status message from tiie DLA auction server 
program, es detected in step 1510, the collector/redistributor calls the routine "process status" in step 1512 to 
process the status message, and then resumes waiting for another event. If tiie coOector/redistributor is a first-line 
coltector/redistributor, and tiie collector/redistributor recehres a request from a DLA client program to connect to an 
ongoing auction, as detect^ in step 1514, tiie collector/redistributor validates tiie DLA client program against the 
validation database in step 1516. If the DLA client program, and remote bidder tiiat has invoked it, is properiy 
autiiorized, as detected in step 1518, the collector/redistributor accepts the connection and places a unique client 
identifier essodated with an auction ID into an active client Ust in step 1520, and titan resumes weiting for another 
event If, on tiie otiier hand, the collector/redistributor det^ines that tiie client is not autiiorized to participate in die 
desired euction, as detected in step 1518, then the collector/ralistributor refuses the connection request in step 1522 
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and resumes waiting for another event. If the collector/redistributor recewes a client request to terminate connection 
to an auction, as detected in step 1524, the collector/redistributor removes the client from the active client list in step 
1526 and resumes waiting for another event. If the collector/redistributor receives a message from the DLA auction 
server indicating that an auction has finished, as detected in step 1528, the collector/redistributor removes the auction 
ID from the list of active euction lO's in stqi 1530 and then resumes waiting for another event If the 
collector/redistributor receives an auction starting message from the DLA auction server, as detected in step 1 532, the 
collectorlredistrAutor adds the ID of the startmg auction to a list of active auction ID's in step 1534, and then 
resumes waiting for another event. On the other hand, if none of the above-mentioned events are identified, as 
indicated by the negative output in step 1532, the collector/redistributor simply continues to wait for another event. 

Figure 16 is a flow control diagram for the routine "process status." The routine "process status" is called 
by the collector/redistributor in step 1512 in Figure IS. In step 1602, the collector/redistributor checks the auction ID 
in the status message against an internal list of active auctions. If the auction ID is not in the acthre auctions list, as 
detected in steps 1504, the routine "process status" returns to step 1606. Note, as an alternate embodiment, the 
routine "process status" could assume that the status message relates to a new auction for which a start auction 
message has not yet bran received, and add the auction ID to the list of active auction ID's and continue processing in 
step 1608. Altemathrely, the collector/redistributor could initiate a dialog with the DLA auction server to 
resynchronize information concerning the current state of all ongoing auctions. In step 1608, the 
collector/redistributor checks the lot number in the status message against the current lot number for the auction 
kientffied by the auction 10 included in the status message. If the lot number is a new lot number, or, in other words, if 
the lot number in the status message does not correspond to the current tot number associated with the auction in the 
acthre auction list maintained by the collector/redistributor, as detected in step 1610, the collector/redistributor 
updates the current lot number for the auction identified by the auction ID in the active auction list maintained by the 
collector/redistributor in step 1612. For choice and quantity lots, the process "status," in step 1608, also reads the 
available inventory from the incoming status message in ordv to subsequently compare the desired inventory of the 
incoming bids to the currently available inventory to make sure that the incoming bids have enough inventory to meet 
the conditions set by the auctionea' on the floor, e.g. a iteclaration of "one money!" indicating that all the items in the 
lot must be sold at once, and to make sure that lots have enough inventory for the bidders, e.g. a bidder that will take 
no less than 100 units in a quantity lot may not submit a bid for which there ere only 90 urats left. These additional 
filter conditions for choice end qumitity lots are carried out in st^ 1505 of F^ure 15. Then, in the loop represented 
by steps 1614, 1616, and 1618. the collector/redistributor forwards the status message to the clients connected to 
the collector/redistributor, in the case of e first-line collector/redistributor, or forwards the status message to all 
coOector/redistributors at the next-kiwest level connected to the collector/redistributor. 

Rgure 17 is a block diagram of the DLA auction servo^ program. The memory component 1704 and OS 
interface component 1716 are similar to the memory and OS interface components of the collector/redistributor and 
DLA client program, discussed previously with regard to Hgures 12 and 14, and will not be discussed further in the 
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interest of brevity. The DLA auction server program 1702 includes the following components: (1) a 
collector/redistributor connection manager that maintains up to ten network connections with root-level 
collector/redistributor nodes, sending status messages and other types of messages to the collector/redistributor nodes 
and receiving bid messages and other types of messages from collector/redistributor nodes; (2) a database interface 
5 component 1710 that represents an interface to an extensive database that contains information about ongomg and 
upcoming auctions, including detailed inventory lists, inventory sequences, lot ass^nm&its, and the current, 
instantaneous state of any particular ongoing auction; (3) a auction console connection manager contponent 1712 that 
manages TCP/IP connections to one or more DLA auction consote programs running on-site computers; (4) an 
encryption/decryption modide 1714 that decrypts incoming messages and oicrypts outgoing messages; and (5) a 

10 auction server component 1716 that interconnects the memory component 1704, the OS interface component 1706, 
the database component 1710, the collector/redistributor manager 1708, and the auction console connection manager 
1 71 2 to implement the functionaEties provided by the DLA auction server to facilitate Intmet-based live auctions. 

Figure 18 is a flow control diagram for that portion of the DLA auction server program invohred in 
implementing real-time Internet-based live euctions. This portion of the DLA auction server program essentially watts 

15 in an endless loop for events to occur, and then handles the events. If the DLA auction server program receives an 
auction start message from and DLA auction console program, as detected in step 1802, the DLA auction server 
program adds the auction ID to a list of acthre auctions, sends s start message to root-level coUector/retfistributor 
nodes in step 1804, end then resumes waiting for another event If tin OLA auction server program receives a bid 
from a root-level collector/redistributor node, as detected in step 1806, DLA at^tion server program calls the routine 

20 "bid" in step 1 808 to handle the recmved bid message and then resumes waiting for another evoit 

If the DLA auction server program receives one of a number of different types of sync messages from a DLA 
auction console program, as detected in st^ 1814, the DLA auction server program calls the routine 'sync," in step 
1816, to handle the sync messages and then resumes waiting for another event In some cases, the DLA auction 
server generates status messages upon receiving certain sync messages, ami forwards the status messages on to 

25 remote bidders via the collector/redistributor nodes. If, for example, the DLA auction server recehres a ''Next Lot* or 
'Pass' sync message from the consolOr it forwards the lot cursor to the next lot and generates a new static message. 
As another example, if the OLA auction server receives e 'Console State* sync message from the console, it sets the 
state of the lot to that state and gerarates a new status message to the clients, where the states may inchide certam 
of the active states discussed above with reference to Figure 2. If the DLA auction server receives a "Flash Text' sync 

30 messap from the console, it sets a flash text field for the lot to that flash text message and generates a new status 
message to the clients. If the DLA auction server receives a 'Jump Lot" sync message from the console, it sets a lot 
cursor to the new lot and generates a new status messege to the clients. These various types of sync messages ere 
handled by the routine 'sync,' called in step 1816. That routine essentially maintains the ^rrespondence between the 
computational image of live auctions stored in the DLA database and the live auctions via the incoming sync messages 
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from the DLA auction console, and generates status messages, when necessary, to update the auction status screen 
displayed to remote bidders. 

If the OLA auctim server program receives an end of auction message from an DLA auction console program, 
as detected in step 1818, the DLA auction server program removes the indicated auction ID from the list of active 
auction IDs sends an end of auction message to all root-level collector/redistributor nodes in step 1820, and then 
resumes waiting for another event. If the OLA atction server program recehres e terminatitni indmation as detected in 
step 1820, then the OLA auction server program tenntnates, in step 1822. Otherwise, the DLA auction server resumes 
waiting for another event. 

Figure 19 is flow control program diagram of tiie routine "bid." This routine is called by the DLA auction 
senm program in step 1808 in Figure 18. In step 1902, tiie OLA auction server program checks the auction ID and lot 
numbers in the bid against the DLA database to make sure the bid is still valid. If the bid is not valid, as detected in 
step 1904, the routine "bid" returns in step 1908. Otiterwise, the DLA auction server (ffogram may update the 
database in step 1908 in order to facilitate filterirq of other received bids. If the bid is received in from the DLA 
auction console, as detected by the routine "bid" in step 1910, then, in step 1912, the routine "bid* generates a status 
message to send to the remote bidders in order to update the rmote bidders'auction status delays. If, on the other 
hand, the bid is received from a remote bidder, the DLA auction server forwards the bid to tte appropriate OLA auction 
console program in step 1914. 

Figure 20 is a flow control program diagram of the routine "sync." The routine "sync" is called by the DLA 
auction server in step 1816 in Figtffe 18. In step 2002, the OLA auction server updates in-memory structures and 
database entries in order to ensure that the computational represMation of the Ihre auction from which the sync 
message is sent corresponds to the state of the live auction.. If the sync message describes a state change that must 
be passed on to remote bidders for display by the DLA client program, then the routine "sync" generates a 
corresponding status message and forwards it to the root4evel collectcr/redistrifautor nodes in step 2006. The various 
sync messages include: (1) "Asklncrement," a message that sets the asking price and the ask inoement; (2) "Console 
State," a message that contains one of the following states: "fair warnmg," "last chance," "sold," "sold on the floor," 
"pass," "next item;"; (3) 'Flash Text" a message used to convey textual massages representing the auctionw's 
commonts; and (4) "Lot Sequencer," a message that represents a re-sequencing of lots. 

Rgure 21 is a block diagram of die OLA auction console program. The OLA auction console program 
components are neariy identical to the components with the OLA climit program, described above witii reference to 
Figure 1Z The only substantive differences are tiiat tiie TCP/IP connection manager 2104 receives messages from die 
DLA auction server program and sends messages to the OLA auction server program and that the console module 2106 
mterconnects the TCP/IP connection manager module 2104, tiie tim mterface module 2106, tiie OS interface 
component 2108, and the memory component 2110 in order to implement tiie functionalities provided by tiie DLA 
auction console. 
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Figure 22 is a flow control diagram of that portion of the QLA auction console program concerned with 
facilitating a live auction. In step 2202, the OLA auction console program displays the OLA console screen to the OLA 
human proxy. Then, the DLA auction console pmgram waits for any number of ififferoit events to occur and then 
handles those events. If the DLA auction console program receives a bid from the OLA auction server, as detected in 
5 step 2204, the OLA auction console program displays the bid to the console screen in step 2206 and resumes waiting 
for another event If the DLA auction console program receives a status update input from the console screen, as 
detected in step 2212, the OLA auction console program sends a corresponding sync message to the DLA auction 
server in step 2214 and resumes waiting for mother event If the DLA auction consote program receives an indication 
from the console screen of the start of an auction, as detected in step 2216, the DLA euction console program snids a 

10 start of auction message to the auction server, in step 2218 and tten resumes waiting for anoth^ event If the DLA 
auction console program receives an indication of the end of an auction, as detected in step 2220, the DLA auction 
console program sends an end of auction message to the DLA auction server program in step 2222 and resumes 
waiting for another event. If the DLA auction console program recehres a resync request from the DLA auction server, 
as detected in step 2224, then the DLA auction console program calls a "resync" routine to undertake and complete a 

15 resync cfialog with the DLA auction server program in step 2226. The resync routine facilitates an exchange of sync 
messages; and will not be discussed further. If the DLA auction console program recehns a termmation indication, as 
detected in step 2228, the DLA auction console program terminates in step 2230. Otherwise, the DLA auction console 
program resumes waitmg for another event 

Although the present mvention has been described m terms of preferred embodiments, it is not intended that 

20 the invention be limitod to these embodiments. Modifications within the spirit of the invention will be apparent to 
those skilled in the art. The foregoing descriptkm, for purposes of explanation, used specific nomenclature to provide a 
thorough understanding of the invention. However, it will be apparent to one skilled in the art that the specific details 
are not required in order to practice the invention. The foregoing descriptions of specific embodiments of the present 
invention are presented for purpose of illustration and description. They are not intended to be exhausthre or to limit 

25 the invention to the precise forms disclosed. It is intended that the scope of the invention be defined by the following 
claims and their equivalents: 
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CUIMS 

1 . A system for conducting real time auctions, comprising: 

an auction server which maintains real time auction state information based at least upon bid 
messages from remote uso^ and 

a plurality of nodes coupled between the auction server and the remote users, the nodes configured 
to pass auction state information from the auction server to the remote users, and configured to pass bid 
messages from the rvnote users to the auction server; 

wherein at least some of the plurality of nodes are configured to filter bid messages from the 
remote users based on state infonnation recehred from the auction server, to thereby prevent bid messages 
that do not affect the state of an auction from unnecessarily being passed to the auction server. 

2. The system as in Claim 1, wherein the plurality of nodes include multiple leaf nodes, each leaf node 
being configured to maintain connections with a respecthre subset of the remote users. 

3. The system as in Claim 2, wherein the plurality of nodes are coupled to the auction server to form a 
tree structure. 

4. The system as in Clean 1, wherein at least some of the nodes are configured to block bid messages 
based on comparisons of bid amounts of the bid messages to a current high bid. 

5. The system as in Claim 1, wherein at least some of the nodes are configured to block bid messages 
that do not correspond to a ctorently valid auction. 

6. The system as in Claim 1, wherein at least some of the nodes are configured to block bid messages 
that do not corre^ond to a currently valid lot. 

7. The system as in Claim 1« wherein at least some of the nodes are configured to block a request by 
a user to connect to a currem auction when the user is not authorized to participate in the current auction. 

8. The system as in Claim 1, further comprising an auction console program that communicates with 
the auction server and provides functions for a human operator to participate in a Ihre auction as a proxy for the 
remote users. 

8. The system as in Claim 8, wherein the auction console program includes user interface functions 
for the human operator to setect predetermmed auction status messages to disseminate to the remote users. 

10. The system as in Claim 8, wherein the auction console program comprises an applet which runs 
wttMn a web browser program. 

11. The system as m Claim 1, further comprising a cfient program that is adapted to be used by the 
remote users, the client program configured to encapsulate a bid submission from a remote user for transmission to the 
auction server, and to display auction status information to the remote user. 

12. A method of reducing a load on an auction serv^ that maintains a state of one or more real time 
auctions, comprisingi at a node which is coupled between the auction server and a plurality of remote users: 
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(a) receiving from the auction server and storing state information wliich indicates a current 
state of at least one auction; 

(b) receiving a bid message from a remote user; 

(c) comparing information contained witiiin the bid message to the state information stored 
in (a) to determine whether the message represents a valid bid; and 

(d) transmitting at least a portion of the bid message to the auction server for processing 
only if the bid is determined in (c) to te valid. 

13. The method as in Claim 12, wherein the node is a leaf node of a hierarchical node structure in 
which valid bids are passed upward from leaf nodes to the auction server. 

14. The method as in Claim 13, further comprising performing (aHd) at each of a plurality of leaf nodes 
of the hierarchical node structure, wherein each leaf node processes bid messages from a respective subset of the 
plurality of remote users. 

15. The method as in Claim 12, wherein (c| comprises comparing a bid amount in the message to a 
current high bid. 

1& The method as in Claim 12, whermn (c) comprises determining whether the message identifies a 
currently vaGd auction. 

17. The method as in Claim 12, wherein (c) comprises detmiining whether the message identifies a 
ctOTently valid lot. 

18. The method as in Claim 12, further comprising blocking, at the node, e request by e user to connect 
to a current auction virhen the user is not euthorized to ptfticipete in the auction. 

19. The method as in Claim 12, wherein the bid message represents a bid submission in a hybrid 
Gve/online auction in which the remote users compete with auction anendees. 

20. The method as in Claim 19, further comprising forwarding at least a portion of the bid message 
from the auction server to a human operator that acts as a proxy for the remote users, to allow the human operator to 
place the bid on behalf of the remote user. 



-23- 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



1/22 



PCT/US99/31061 



NO UORE ITEMS IN LOT 




REQSIER 



F/a / 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 PCT/US99/31061 

2/22 




EGSeMiUODNBOOS 



f/G. 2 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



PCT/US99/31061 




SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



PCT/US99/31061 



4/22 




SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



5/22 



PCT/US99/31061 



506 



REQUEST CUENT REGISTRATION SCREEN C 



21. 



5/0 



USER IDC 
PASSWORD 



5f2 



RESPOND TO INFORMATION REQUEST 



5/6 




5/a 



RESPOND TO INFORMATION REQUEST 



522 



PHONE I I 
CRED IT CARDCZ3 
BANK I 1 



EMPLOYER! 



524 



RESPOND TO INFORMATION REQUEST 



528 



TERMS & CONDITIONS 



urn. 



DB0C8EE 



523 



RESPOND BY A6REDN6 OR DISAGREEING 



ri 



^508 



RETURN REGISTRATION SCREEN 



^5/4 



RETURN DATA COLLECTION SCREEN 



j-520 



RETURN DATA COLLECTION SCREEN 



^526 



RETURN TERMS & CONDITIONS 



J 

502 



f/G. 5 



) 

504 



SUBSTITUTE SHEET (RULE 26) 



wo 0(M39735 



6/22 



PCTAJS99/31061 



602 



REQUEST AUCTION LIST FORM 



BlGiUICiniKOilSI/U/nSEIIII 

EirS BID NOV 3/9/99 DENIED 
AliCrSiUIIIOllES 3/10/99 liUIIG 



608 



SELECT AUCTION/STATUS [ 



S/2 




ef4 



RETURN REQUESTED INFORMATION 



TERMS & CONDITIONS 

AGREE DSACTEE 



6f3 



RETURN AGREEMENT OR DISAGREEMENT 



BGIUCmi HOUSE 

ED'S BID NOW 3/9/99 DEMED 
A[iirSM]UES3/1i|/99fillM 



Z2 RETURN AUCTION LIST 



RETURN INFORMATION COLLECTION FORM 



_] RETURN TERMS & CONDITIONS 



620 



F/G. 6 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



7/22 



PCTAJS99/31061 



702 



REQUEST AUCTION LIST [ 



RMKintKIII!l/|]/9S/imOKD 
JDSItiyn(lVVQlllRNED 
ED'S BID NOW 3/9/99 DEie 

Aucrs/uflniiEs 3/10/99 uiniffi 



706 



SELECT AUCTION/INVENTORY 



2i. 



7/0 




SELECT CATEGORY 



, ^ KITCHEN TABLE - STEa 
-^-^^-nKITCHDI TABLE - OAK 
KITCHEN TABLE - CHERRY 
KITCHEN TABLE-PLYWOOD 



SELECT LOT 



722 



wm TASLE m 



SELECT PRE-BID 



726 



FiiCEABIDFDSaYWDODME 
^OPENING BID $100 
HAXIUUUBiO $200 
IDCHN PASm 

IBl 



PUCE PRE-BID 



7/2 



7/S 



IN 



722 



728 



704 



RETURN AUCTION LIST 



^708 



J RETURN UST OF CATEGORIES 



j^7f4 



J RETURN LIST OF LOTS 



720 



RETURN DESCRIPTION OF LOT 



724 



RETURN PRE-BID FORM 



F/G. 7 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



8/22 



PCT/US99/31061 



802 



REQUEST AUCTION LIST 



BCiUIIMIiQlS 
80S ■^,iHfi«CIIIICIIT 
ED'S BID NOW 

jmcrsAHnniEs 



DENO 
WIIDIS 



806 



SELECT AUCTION/JOIN [ 



808 



PLYWOOD TABLE 




HIGH BID 


$50 


mi UVE UDDER 




ASKING PRICE: 


$100 


ACTIVE 


np 



PLYWOOD TABLE 

HIGH BID $100 

FROM INET #5 

ASKING PRICE: $150 

ACTIVE (ID] 



^8f8 



PLYWOOD TABLE 




HIGH BID 


$150 


FROM 


INET #5 


ASKING PRICE: 


$200 


FAIR WARNING 


[El 



REQUEST BID 



REQUEST BID 



8f6 



820 



^-804 

ZD RETURN AUCTION LIST 



8/0 



STATUS 



^8/2 



3 STATUS 



8f4 



STATUS 



F/G. S 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



PCT/US99/31061 



9/22 



r r ( 



s 



cn 



£2 



3 
o 



I 



^ ^ 



5 
s 



1 



i 

5 



!2 



o o o o o o 




in 

eg I « I - 



s 



CD 



a o o 

OOOOOOOOOOOO 



"V- 

I 



a 
g 



S 



5 § 



3 
S 



i ^ i ^ 



o 

a 

o ^ 

o o o o o o 



0 

ui 

X 



3 

f 
o 



Si 

Ui 

hi 



i i i 



B 

n. 
ae 

e 

X 

a 

o 

S 



o 



i 
o 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



10/22 



PCTAJS99/31061 



W02- 



LOWER-LEVEL PROTOCOL 
INFORMATION 

STATUS MESSAGE 



AUCTION ID 



LOT ID 



ASK 



HIGH BID 



HIGH BIDDER 



STATUS 



TEXT 



■fooa 

•rfO/2 
\rf0/4 
/0/6 
fO/B 



AVAIUBLE INVENTORY 



■/020 



■fa22 



r/G. /o 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



11/22 



PCT/US99/31061 



/W2- 



LOWER-LEVEL PROTOCOL 
INFORMATION 

BID MESSAGE 



AUCTION ID 



LOT ID 



BIDDER 



BID 



DESIRED INVENTORY 



\rn06 
•/f/4 



SUBSTnVTE SHEET (RULE 26) 



wo 00/39735 



12/22 



PCT/US99/31061 



VARIABLES 
MEMORY 



Ul 



CLIENT 



0 s 
INTERFACE 



CONNECTIVmr 
MANAGER 




TCP/IP 
CONNECTION 
MANAGER 




ENCRYPTION/ 
DECRYPTION 















t202 



r/G. f2 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



PCT/US99/31061 



13/22 



( CUENT REAL TIME AUCTION ) 



DISPLAY AUCTION 
SCREEN AND WAIT 
FOR EVENT 



■/J02 



YES 



YES 




SEND BID 
MESSAGE TO 
COLECTOR/REDISTRIBUTOR 



UPDATE 


AUCTION 


STATUS 


SCREEN 



F/G. fj 



SUBSTITUTE SHEET (RULE 26) 



wo 0009735 



PCT/US99/31061 



14/22 



MEMORY 



f4fO 



DATABASE 
INTERFACE 



AUCTION 
SERVER 
CONNECTION 
MANAGER 




f4/S 



COLLECTOR/ 
DISTRIBUTOR 




/404 



CUENT 
CONNECTION 
MANAGER 



/40S 



0 S 
INTERFACE 



/406 



DECRYPTION 



F/G. f4 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



PCT/US99/31061 



15/22 

(COLLECTOR/REDISTRIBUTOR REAL TIME AUCTIOn) 




ADO AUCTION ID 
TO LIST OF 
ACTIVE AUCTION IDS 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



PCT/US99/31061 



16/22 



( PROCESS STATUS ) 



RETURN 



I 



CHECK AUCTION ID 
AGAINST ACTIVE 
AUCTIONS UST 



F/G. /S 



-feo2 



/604 




CHECK LOT NUMBER 
AGAINST CURRENT LOT 
NUMBER FOR AUCTION 10 




UPDATE CURRENT 

LOT NUMBER 
FOR AUCTION ID 



FOR EACH CONNECTED 
CUENT PARTICIPATING 
IN AUCTION. STARTING 
WITH FIRST 



■f6/4 



SEND STATUS 
MESSAGE TO CUENT 



■f6/6 



rers 




SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



17/22 



PCT/US99/31061 



/704 



MEMORY 



DATABASE 



AUCTION 
CONSOLE 
CONNECTION 
MANAGER 




/7/e 



AUCTION 
SERVER 




1708 



COLLECTOR/ 
DISTRIBUTOR 
CONNECTION 
MANAGER 



/702 
^f7f4 



ENCRYPTION/ 
DECRYPTION 



/706 



0 S 
INTERFACE 



r/G. /7 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



PCT/US99/31061 



18/22 



(auction server real time auction) 




NO 



ADO AUCTION ID TO 
LIST OF ACTIVE 
AUCTIONS, SEND 
START MESSAGE TO 
:OLLECTOR/REDISTRIBUTORS 



/SOS 



BID 

FROM COLLEaOR/ 
REDISTRIBUTOR. " 




fSOS 



fSU 



SYNC 
FROM CONSOLE 

7 



rsrs 



SYNC 



■rs/s 



END 
OF AUCTION 



^/820 



REMOVE AUCTION ID 
FROM LIST OF ACTIVE 

AUCTIONS. SEND END OF 
AUCTION MESSAGE TO 

)OLLECTOR/REDISTRIBUTORS 



f822 



TERMINATE 

9 



RETURN) 



SUBSTITUTE SHEET (RULE 26) 



00/39735 



PCT/US99/31061 



19/22 



(ZED 



r/G. f9 



CHECK AUCTION 
ID/LOT AGAINST 
DATABASE 



i902 



f904 





SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 



20/22 



PCT/US99/31061 



c 



SYNC 



MAKE DATABASE 

ENTRIES AND 
MEMORY UPDATES 



^2002 



2004 




^200S 





GENERATE STATUS 
MESSAGE AND SEND 
TO REMOTE BIDDERS 









F/a 20 



SUBSTITUTE SHEET (RULE 26) 



wo 00/39735 PCT/US99/31061 

21/22 



VARIABLE/ 
MEMORY 



Ul 



2we 



CONSOLE 



d 

0 s 
INTERFACE 



CONNECTIVITY 
MANAGER 




TCP/IP 
CONNECTION 
MANAGER 




ENCRYPTION/ 
DECRYPTION 















r/G. 2/ 



SUBSTITUTE SHEET (RULE 26) 



■<l 



wo 00/39735 



PCT/US99/31061 



4i M 



22/22 



( CONSOLE REAL HME AUCTION ) 
DISPUY CONSOLE SCREEN \ 



F/G. 22 




DISPLAY BID 
TO CONSOLE 
SCREEN 



J2. 



22f4 



SEND SYNC 
MESSAGE TO 
AUCTION SERVER 



^22/£ 



SEND START OF 
AUCTION MESSAGE 
ID AUCTION SERVER 



2222 



SEND END OF 
AUCTION MESSAGE 
TO AUCTION SERVER 



^2226 



RESYNC 



SUBSTITUTE SHEET (RULE 26) 



